Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update d4tools and d4binding #48077

Merged
merged 9 commits into from
Oct 23, 2024
Merged

update d4tools and d4binding #48077

merged 9 commits into from
Oct 23, 2024

Conversation

ramprasadn
Copy link
Contributor

Describe your pull request here


Please read the guidelines for Bioconda recipes before opening a pull request (PR).

General instructions

  • If this PR adds or updates a recipe, use "Add" or "Update" appropriately as the first word in its title.
  • New recipes not directly relevant to the biological sciences need to be submitted to the conda-forge channel instead of Bioconda.
  • PRs require reviews prior to being merged. Once your PR is passing tests and ready to be merged, please issue the @BiocondaBot please add label command.
  • Please post questions on Gitter or ping @bioconda/core in a comment.

Instructions for avoiding API, ABI, and CLI breakage issues

Conda is able to record and lock (a.k.a. pin) dependency versions used at build time of other recipes.
This way, one can avoid that expectations of a downstream recipe with regards to API, ABI, or CLI are violated by later changes in the recipe.
If not already present in the meta.yaml, make sure to specify run_exports (see here for the rationale and comprehensive explanation).
Add a run_exports section like this:

build:
  run_exports:
    - ...

with ... being one of:

Case run_exports statement
semantic versioning {{ pin_subpackage("myrecipe", max_pin="x") }}
semantic versioning (0.x.x) {{ pin_subpackage("myrecipe", max_pin="x.x") }}
known breakage in minor versions {{ pin_subpackage("myrecipe", max_pin="x.x") }} (in such a case, please add a note that shortly mentions your evidence for that)
known breakage in patch versions {{ pin_subpackage("myrecipe", max_pin="x.x.x") }} (in such a case, please add a note that shortly mentions your evidence for that)
calendar versioning {{ pin_subpackage("myrecipe", max_pin=None) }}

while replacing "myrecipe" with either name if a name|lower variable is defined in your recipe or with the lowercase name of the package in quotes.

Bot commands for PR management

Please use the following BiocondaBot commands:

Everyone has access to the following BiocondaBot commands, which can be given in a comment:

@BiocondaBot please update Merge the master branch into a PR.
@BiocondaBot please add label Add the please review & merge label.
@BiocondaBot please fetch artifacts Post links to CI-built packages/containers.
You can use this to test packages locally.

Note that the @BiocondaBot please merge command is now depreciated. Please just squash and merge instead.

Also, the bot watches for comments from non-members that include @bioconda/<team> and will automatically re-post them to notify the addressed <team>.

@mencian mencian marked this pull request as ready for review October 23, 2024 02:40
Copy link
Contributor

coderabbitai bot commented Oct 23, 2024

📝 Walkthrough
📝 Walkthrough

Walkthrough

The pull request introduces a series of changes primarily focused on managing build failures across various recipes. A comprehensive blacklist of recipes has been created, categorizing issues such as compilation failures, missing dependencies, outdated source URLs, and excessive resource consumption. Specific recipes have been flagged for problems including compilation errors on Linux and the need for migration to conda-forge. Additionally, the build.sh script in the d4binding directory has been updated to copy a new build_htslib.sh script, which automates the building process of the HTSlib library. This new script includes checks for environment variables and manages dependencies like zlib and bzip2. Furthermore, the meta.yaml files for both d4binding and d4tools packages have been updated to reflect new versions and build numbers, with d4binding also introducing a run export for subpackage pinning. These changes collectively aim to enhance the management of build processes and address existing failures.

Possibly related PRs

  • Update d4tools to 0.3.11 #51110: Changes in the d4tools package's meta.yaml file include a version update, which may relate to the systematic approach of managing build failures documented in the main PR.
  • bambamc: add aarch64/arm64 builds #51067: The bambamc package update includes a new run_exports section, aligning with the main PR's emphasis on managing dependencies and build issues.
  • longreadsum: add aarch64/arm64 builds #51121: The longreadsum PR introduces builds for aarch64/arm64, which may relate to the main PR's focus on addressing build failures and migration issues.
  • pepnovo: add aarch64/arm64 build #51206: The pepnovo PR adds support for aarch64/arm64 builds, relevant to the main PR's focus on managing build failures and issues.
  • Update hmftools-amber to 4.1_beta #51141: The hmftools-amber update includes version changes and dependency management, which is relevant to the main PR's focus on documenting build failures and issues.
  • Add hmftools-chord 2.1.0_beta #51149: The introduction of the hmftools-chord package includes a new recipe, which may relate to the main PR's focus on managing build failures and issues.
  • Rebuild breseq #51221: The breseq rebuild addresses runtime crashes, relevant to the main PR's focus on documenting build failures and issues.
  • Update diamond recipe #51515: The diamond recipe update includes changes to the build process, aligning with the main PR's focus on managing build failures and issues.
  • Update svdss to 2.0.0 #51519: The svdss update includes significant versioning and dependency changes, relevant to the main PR's focus on managing build failures and issues.
  • [biobb_cp2k] update 5.0.0 #51528: The biobb_cp2k update includes version increments and dependency adjustments, which is relevant to the main PR's focus on managing build failures and issues.

Suggested labels

please review & merge, new version

Suggested reviewers

  • adamhospital

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 1934ecd and 387ff98.

📒 Files selected for processing (2)
  • recipes/d4binding/build.sh (1 hunks)
  • recipes/d4binding/meta.yaml (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • recipes/d4binding/build.sh
🧰 Additional context used
🪛 yamllint
recipes/d4binding/meta.yaml

[error] 1-1: syntax error: found character '%' that cannot start any token

(syntax)

🔇 Additional comments (6)
recipes/d4binding/meta.yaml (6)

1-2: LGTM! Package metadata follows best practices.

The use of Jinja2 variables for name and version is the recommended approach.

🧰 Tools
🪛 yamllint

[error] 1-1: syntax error: found character '%' that cannot start any token

(syntax)


9-11: Excellent addition of run_exports for ABI compatibility!

The pin_subpackage with max_pin="x.x" ensures that downstream packages will use compatible versions, preventing ABI breakage. This aligns perfectly with Bioconda's guidelines for package versioning.


21-22: LGTM! Build requirements are well-specified.

The Rust version requirement and GCC specification are appropriate, with good documentation in the skip-lints section explaining the GCC requirement.


37-40: LGTM! Metadata improvements enhance package documentation.

The additions of license_family and dev_url improve package metadata completeness.


1-41: Verify version compatibility with d4tools.

Since this is a binding package being updated alongside d4tools to version 0.3.11, let's verify the version compatibility between the packages.

✅ Verification successful

Since I can see that both packages (d4binding and d4tools) are at version 0.3.11, I can now generate the final response:

Version compatibility verified between d4binding and d4tools

Both packages are aligned at version 0.3.11, maintaining proper version coordination between the binding package and its core tools.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if d4tools recipe exists and its version matches
# Expected: Both packages should use version 0.3.11

echo "Checking d4tools recipe version..."
if [ -f "recipes/d4tools/meta.yaml" ]; then
    grep "version = " recipes/d4tools/meta.yaml
fi

Length of output: 192

🧰 Tools
🪛 yamllint

[error] 1-1: syntax error: found character '%' that cannot start any token

(syntax)


14-15: Verify the source URL accessibility.

The URL format has changed (removed "-3" suffix). Let's verify the URL is accessible.

✅ Verification successful

The HTTP 302 status indicates a redirect, which is normal for GitHub archive downloads. Let's follow the redirect to ensure the final destination is accessible.


Source URL is accessible and valid

The source URL is working correctly. The initial 302 redirect followed by a 200 status code confirms that the GitHub archive for v0.3.11 is accessible at the specified URL. The removal of "-3" suffix from the URL format is valid for this version.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the source URL is accessible
# Expected: HTTP 200 status code

VERSION="0.3.11"
URL="https://github.com/38/d4-format/archive/refs/tags/v${VERSION}.tar.gz"
curl -sI "$URL" | head -n 1

Length of output: 187


Script:

#!/bin/bash
# Description: Follow redirects and verify the final URL is accessible
# Expected: HTTP 200 status code in the final destination

VERSION="0.3.11"
URL="https://github.com/38/d4-format/archive/refs/tags/v${VERSION}.tar.gz"
curl -sLI "$URL" | grep "HTTP/"

Length of output: 202


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 8

🧹 Outside diff range and nitpick comments (4)
recipes/d4binding/build.sh (2)

Line range hint 14-15: Consider adding error handling for install.sh execution.

While the script uses -e flag for error handling, explicit error handling for the installation step would provide better debugging information.

Consider wrapping the installation step:

-cd d4binding 
-./install.sh
+cd d4binding || exit 1
+if ! ./install.sh; then
+    echo "Error: d4binding installation failed"
+    exit 1
+fi

I can now generate the final response based on the meta.yaml content.

The TODO comment about Rust compiler pinning needs to be addressed

The meta.yaml file currently uses rust >=1.30 in the build requirements instead of the recommended {{ compiler('rust') }} syntax. This confirms the validity of the TODO comment. The current approach:

  • Doesn't follow Bioconda's best practices for compiler pinning
  • May lead to less reproducible builds
  • Is acknowledged in skip-lints section, but specifically for gcc usage, not Rust

Required changes:

  • Replace rust >=1.30 with {{ compiler('rust') }} in meta.yaml's build requirements
  • Remove the TODO comment and related environment variable exports in build.sh once the change is made
🔗 Analysis chain

Line range hint 4-7: Address the TODO comment about Rust compiler pinning.

The TODO comment indicates that the CARGO_* environment variables are a temporary solution. According to Bioconda best practices, using the conda-forge's Rust compiler through {{ compiler('rust') }} in meta.yaml is preferred for better build reproducibility.

Let's verify if the Rust compiler is properly specified in meta.yaml:


Let me gather more information about the meta.yaml file to better understand the build requirements.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if meta.yaml properly specifies the Rust compiler
rg --type yaml 'compiler.*rust' recipes/d4binding/meta.yaml

Length of output: 61


Script:

#!/bin/bash
# Let's first check if the meta.yaml file exists and see its content
cat recipes/d4binding/meta.yaml

Length of output: 1148

recipes/d4binding/meta.yaml (1)

Line range hint 14-14: TODO comment needs attention.

The TODO comment references waiting for version 0.3.5, but the package is currently at version 0.3.4. This comment may be outdated since we're using a formal release tag v0.3.4-3.

Consider removing or updating this TODO comment to reflect the current status.

recipes/d4binding/build_htslib.sh (1)

1-63: Consider adding better error handling and logging.

For a build script in a bioconda recipe, consider these improvements:

  1. Add a logging function to standardize output
  2. Add more descriptive error messages
  3. Consider adding cleanup trap for interrupted builds

Example logging function:

log() {
    echo "[$(date +'%Y-%m-%dT%H:%M:%S%z')]: $*" >&2
}

trap 'log "Error: Build failed on line $LINENO"' ERR

This will help with debugging failed builds in the bioconda infrastructure.

🧰 Tools
🪛 Shellcheck

[warning] 28-28: Quote this to prevent word splitting.

(SC2046)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 7664e5a and 6755d94.

📒 Files selected for processing (5)
  • build-fail-blacklist (0 hunks)
  • recipes/d4binding/build.sh (1 hunks)
  • recipes/d4binding/build_htslib.sh (1 hunks)
  • recipes/d4binding/meta.yaml (1 hunks)
  • recipes/d4tools/meta.yaml (1 hunks)
💤 Files with no reviewable changes (1)
  • build-fail-blacklist
🧰 Additional context used
🪛 Shellcheck
recipes/d4binding/build_htslib.sh

[warning] 28-28: Quote this to prevent word splitting.

(SC2046)

🔇 Additional comments (5)
recipes/d4binding/meta.yaml (2)

8-10: LGTM: Appropriate version pinning strategy added.

The addition of run_exports with strict version pinning (x.x.x) aligns with Bioconda's guidelines for preventing API/ABI breakage. This ensures that downstream packages will be constrained to the exact version they were built against.


Line range hint 15-16: Verify the source URL and checksum.

The source URL uses a specific tag format v{{ version }}-3. Let's verify this is the correct release.

recipes/d4tools/meta.yaml (3)

Line range hint 1-58: LGTM! The recipe updates look good.

The changes include:

  • Version bump to 0.3.11
  • Build number increment
  • Added run_exports for better dependency management
  • Added linux-aarch64 platform support

The recipe maintains all necessary build requirements and follows Bioconda's best practices.


12-14: Verify the run_exports pinning strategy.

The addition of run_exports with max_pin="x.x" means downstream packages will be constrained to the same minor version. This is generally good practice for maintaining ABI compatibility, but let's verify this is the intended constraint level for d4tools.


Line range hint 8-9: Verify SHA256 checksum for the new version.

Let's verify the SHA256 checksum matches the source tarball.

@@ -8,5 +8,7 @@ export \
CARGO_NET_GIT_FETCH_WITH_CLI=true \
CARGO_HOME="${BUILD_PREFIX}/.cargo"

cp $RECIPE_DIR/build_htslib.sh d4-hts/build_htslib.sh
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Enhance robustness of the build_htslib.sh copy operation.

The current copy operation lacks error handling and directory verification. Consider adding these safety checks to prevent build failures.

Here's a more robust implementation:

-cp $RECIPE_DIR/build_htslib.sh d4-hts/build_htslib.sh
+if [ ! -f "$RECIPE_DIR/build_htslib.sh" ]; then
+    echo "Error: build_htslib.sh not found in recipe directory"
+    exit 1
+fi
+mkdir -p d4-hts
+cp "$RECIPE_DIR/build_htslib.sh" d4-hts/build_htslib.sh
+chmod +x d4-hts/build_htslib.sh
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
cp $RECIPE_DIR/build_htslib.sh d4-hts/build_htslib.sh
if [ ! -f "$RECIPE_DIR/build_htslib.sh" ]; then
echo "Error: build_htslib.sh not found in recipe directory"
exit 1
fi
mkdir -p d4-hts
cp "$RECIPE_DIR/build_htslib.sh" d4-hts/build_htslib.sh
chmod +x d4-hts/build_htslib.sh


set -ex

pushd ${OUT_DIR}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Validate required environment variables.

The script assumes OUT_DIR is set but doesn't validate it. Add validation to prevent unclear errors:

+if [ -z "${OUT_DIR}" ]; then
+    echo "ERROR: OUT_DIR environment variable is not set"
+    exit 1
+fi
+
 pushd ${OUT_DIR}
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
pushd ${OUT_DIR}
if [ -z "${OUT_DIR}" ]; then
echo "ERROR: OUT_DIR environment variable is not set"
exit 1
fi
pushd ${OUT_DIR}


rm -rf ${OUT_DIR}/htslib

git clone -b ${HTSLIB_VERSION} http://github.com/samtools/htslib.git
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Use HTTPS instead of HTTP for git clone.

Using HTTP for git operations is less secure. Switch to HTTPS:

-git clone -b ${HTSLIB_VERSION} http://github.com/samtools/htslib.git
+git clone -b ${HTSLIB_VERSION} https://github.com/samtools/htslib.git
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
git clone -b ${HTSLIB_VERSION} http://github.com/samtools/htslib.git
git clone -b ${HTSLIB_VERSION} https://github.com/samtools/htslib.git

exit 0
fi

set -ex
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Enhance shell script safety settings.

Consider adding additional safety flags to prevent common shell script issues:

-set -ex
+set -euxo pipefail

This change will:

  • -u: Exit on undefined variables
  • -o pipefail: Ensure pipeline failures are caught
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
set -ex
set -euxo pipefail

Comment on lines +27 to +33
function is_musl() {
if [ ! -z $(echo $TARGET | grep musl) ]; then
return 0
else
return 1
fi
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Fix shell quoting in musl detection.

The current implementation is vulnerable to word splitting. Quote the grep result:

 function is_musl() {
-	if [ ! -z $(echo $TARGET | grep musl) ]; then 
+	if [ ! -z "$(echo "$TARGET" | grep musl)" ]; then 
 		return 0
 	else
 		return 1
 	fi
 }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
function is_musl() {
if [ ! -z $(echo $TARGET | grep musl) ]; then
return 0
else
return 1
fi
}
function is_musl() {
if [ ! -z "$(echo "$TARGET" | grep musl)" ]; then
return 0
else
return 1
fi
}
🧰 Tools
🪛 Shellcheck

[warning] 28-28: Quote this to prevent word splitting.

(SC2046)


is_musl || perl -i -pe 's/CFLAGS *=/CFLAGS = -fPIC/g' Makefile

make -j8 lib-static
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Optimize parallel compilation.

Instead of hardcoding -j8, use the available CPU cores:

-make -j8 lib-static
+nproc_bin="$(command -v nproc)"
+if [ -n "$nproc_bin" ]; then
+    make -j"$($nproc_bin)" lib-static
+else
+    make -j8 lib-static
+fi
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
make -j8 lib-static
nproc_bin="$(command -v nproc)"
if [ -n "$nproc_bin" ]; then
make -j"$($nproc_bin)" lib-static
else
make -j8 lib-static
fi

Comment on lines +50 to +52
#The original file in the repo is lacking -L in the curl command so it doen't work
curl -L http://sourceware.org/pub/bzip2/bzip2-1.0.8.tar.gz | tar xz
cd bzip2-1.0.8
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Fix typo in comment and enhance bzip2 download safety.

The comment has a typo and the download lacks safety measures:

-#The original file in the repo is lacking -L in the curl command so it doen't work
-curl -L http://sourceware.org/pub/bzip2/bzip2-1.0.8.tar.gz | tar xz
+# The original file in the repo is lacking -L in the curl command so it doesn't work
+BZIP2_SHA256="ab5a03176ee106d3f0fa90e381da478ddae405918153cca248e682cd0c4a2269"
+curl --retry 3 --retry-delay 3 -L 'https://sourceware.org/pub/bzip2/bzip2-1.0.8.tar.gz' -o bzip2.tar.gz
+echo "${BZIP2_SHA256}  bzip2.tar.gz" | sha256sum -c
+tar xzf bzip2.tar.gz
+rm bzip2.tar.gz
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
#The original file in the repo is lacking -L in the curl command so it doen't work
curl -L http://sourceware.org/pub/bzip2/bzip2-1.0.8.tar.gz | tar xz
cd bzip2-1.0.8
# The original file in the repo is lacking -L in the curl command so it doesn't work
BZIP2_SHA256="ab5a03176ee106d3f0fa90e381da478ddae405918153cca248e682cd0c4a2269"
curl --retry 3 --retry-delay 3 -L 'https://sourceware.org/pub/bzip2/bzip2-1.0.8.tar.gz' -o bzip2.tar.gz
echo "${BZIP2_SHA256} bzip2.tar.gz" | sha256sum -c
tar xzf bzip2.tar.gz
rm bzip2.tar.gz
cd bzip2-1.0.8

Comment on lines +38 to +43
if [ "x${ZLIB_SRC}" != "x" ]
then
tar xz ${ZLIB_SRC}
else
curl -L 'http://github.com/madler/zlib/archive/refs/tags/v1.2.11.tar.gz' | tar xz
fi
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Enhance download safety for zlib.

The current implementation lacks important safety measures:

 else
-	curl -L 'http://github.com/madler/zlib/archive/refs/tags/v1.2.11.tar.gz' | tar xz
+	ZLIB_SHA256="629380c90a77892b5c0119a3be631f21e391faa5e93c7b5a5e2ad35d84f7f178"
+	curl --retry 3 --retry-delay 3 -L 'https://github.com/madler/zlib/archive/refs/tags/v1.2.11.tar.gz' -o zlib.tar.gz
+	echo "${ZLIB_SHA256}  zlib.tar.gz" | sha256sum -c
+	tar xzf zlib.tar.gz
+	rm zlib.tar.gz
 fi

Changes:

  • Added SHA256 checksum verification
  • Added retry logic for network resilience
  • Switched to HTTPS
  • Added explicit download instead of piping to tar
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
if [ "x${ZLIB_SRC}" != "x" ]
then
tar xz ${ZLIB_SRC}
else
curl -L 'http://github.com/madler/zlib/archive/refs/tags/v1.2.11.tar.gz' | tar xz
fi
if [ "x${ZLIB_SRC}" != "x" ]
then
tar xz ${ZLIB_SRC}
else
ZLIB_SHA256="629380c90a77892b5c0119a3be631f21e391faa5e93c7b5a5e2ad35d84f7f178"
curl --retry 3 --retry-delay 3 -L 'https://github.com/madler/zlib/archive/refs/tags/v1.2.11.tar.gz' -o zlib.tar.gz
echo "${ZLIB_SHA256} zlib.tar.gz" | sha256sum -c
tar xzf zlib.tar.gz
rm zlib.tar.gz
fi

@mencian mencian merged commit cc53905 into bioconda:master Oct 23, 2024
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants